home *** CD-ROM | disk | FTP | other *** search
- Path: user1.mnsinc.com!huang
- From: huang@mnsinc.com (Szu-Wen Huang)
- Newsgroups: comp.lang.c
- Subject: Re: Tradition or what?
- Date: 16 Mar 1996 00:10:15 GMT
- Organization: Monumental Network Systems
- Message-ID: <4id0t7$9nr@news1.mnsinc.com>
- References: <4g0elg$mdr@redstone.interpath.net> <4hpd8a$d70@alterdial.UU.NET> <1996Mar8.153250.115645@kuhub.cc.ukans.edu> <4hqfug$19l@news.interpath.net> <4hqkso$gno@news1.mnsinc.com> <1996Mar15.163722.6685@pyra.co.uk>
- NNTP-Posting-Host: user.mnsinc.com
- X-Newsreader: TIN [version 1.2 PL2]
-
- Mark Bluemel (markb@pyramid.com) wrote:
- : Szu-Wen Huang (huang@mnsinc.com) wrote:
-
- : : Let me join in. I use magic numbers for states in parsing tables,
- : : and will shoot anybody who suggests I should #define state numbers.
- : : I hope we buried the issue, now that I've given one good place to
- : : use magic numbers instead of #define's.
-
- : May I respectfully suggest that #defines would be clearer and enumerations
- : clearer still ?
-
- No, it won't be, because the states don't always have logical
- significance. For example, the parser state machine for a simple
- regular expression [A-Za-z]*=[0-9]* might look:
-
- switch (state) {
- case 0: if (isalpha(input)) ...
- else if (input == '=') state = 1;
- break;
- case 1: if (...
- }
-
- In this case, I don't believe clarify is an issue, first of all,
- because without the state diagram, the code is next to useless
- to a reader (these code tend to be long). A practical parser
- would have many more states, and #defining those would both be
- a bother and serve no practical purpose in terms of readability.
- In this case, what would you name the states?
-
-